home *** CD-ROM | disk | FTP | other *** search
/ Celestin Apprentice 4 / Apprentice-Release4.iso / Utilities / Programming / Mac F2C 1.2.2 / Mac F2C Documentation / Mac F2C Known Bugs < prev    next >
Encoding:
Text File  |  1995-05-30  |  9.6 KB  |  205 lines  |  [TEXT/MMCC]
  1.     ******************************************************
  2.     ******************************************************
  3.  
  4.                   KNOWN BUGS in Mac F2C v1.2.1 
  5.  
  6.     ******************************************************
  7.     ******************************************************
  8.  
  9.  
  10. Most of the problems with the user interface (U/I) have been fixed as a 
  11. result of building Mac F2C version 1.2 with Codewarrior and Codewarrior's 
  12. SIOUX console library.  However, several new U/I problems have been 
  13. introduced.  This will be fixed in future releases when I implement my own 
  14. status window (or Codewarrior improves theirs).  These, and other U/I 
  15. problems are described below.
  16.  
  17. There are no code generation problems in version 1.2 that I know of.  All 
  18. of the know problems with version 1.1 have been fixed as far as I and my 
  19. testers can tell.  For historical reference (and just in case they 
  20. "re-appear"), they are described at the end of this document.
  21.  
  22.  
  23. KNOWN USER INTERFACE PROBLEMS:
  24.  
  25.     - If Mac F2C is in the background when it needs to display an alert, 
  26.       sometimes the dialog is automatically dismissed when Mac F2C is 
  27.       brought to the front.  This bug is due to undesired interaction 
  28.       with the SIOUX console and is fixed in version 1.3 to be released 
  29.       this summer.
  30.       
  31.       Workaround:  try the translation again, but this time keep Mac F2C
  32.                    in the foreground.
  33.       
  34.     - If Mac F2C is translating in the background, it requests to come to 
  35.       the foreground after each translation, even when there are no problems 
  36.       or alerts to post.  This is fixed in version 1.3 to be released this 
  37.       summer.
  38.       
  39.       Workaround:  bring Mac F2C into the foreground as required, or let
  40.                    Mac F2C translate in the foreground.
  41.  
  42.     - Mac F2C will trigger a compile of CodeWarrior PPC or CodeWarrior 68K,
  43.       but NOT both, even if both have appropriate projects open.  This is 
  44.       fixed in version 1.3 to be released this summer.
  45.       
  46.       Workaround:  use AppleScripts to drive coordinated "makes" involving
  47.                    Mac F2C and both CW PPC and CW 68K.
  48.       
  49.     - Mac F2C will not trigger compiles by the Symantec Project Manager. 
  50.       This will be fixed in version 1.3 to be released this summer.
  51.       
  52.       Workaround:  use AppleScripts to drive coordinated "makes" involving
  53.                    Mac F2C and SPM.
  54.                    
  55.     - Mac F2C does not conform to the AppleEvent Standard Object Model.  
  56.       This is fixed in version 1.3 to be released this summer.
  57.       
  58.     - Mac F2C does not call WaitNextEvent as often as it should during a 
  59.       translation.  This is fixed in version 1.3 to be released this 
  60.       summer.
  61.  
  62.     - The cursor flickers between an I-beam and an arrow while over an 
  63.       editable text field in a dialog box.  This is due to an unwanted 
  64.       interaction with the SIOUX console window.  Unknown when this will 
  65.       be fixed.
  66.       
  67.     - The "Undo" command does not work.  It is not implemented at this time.
  68.     
  69.     - The "Save" command doesn't exist (only "Save As") and Mac F2C doesn't 
  70.       remember what file it saved to after the first save.  
  71.     
  72.     - The "Close" command does not work.  It is not implemented at this time.  
  73.       There is no way to close the translation status window in this version 
  74.       of Mac F2C.
  75.       
  76.     - The translation status window is always saved as a Codewarrior text 
  77.       file, regardless of the creator code specified in the "Mac F2C 
  78.       Preferences" dialog.  
  79.       
  80.     - The translation status window has an ugly, silly title.  Obviously I 
  81.       could write code to change the window's title.  But because the title 
  82.       is set by the Codewarrior SIOUX library when it creates the window, 
  83.       I can only change it *after* the window appears.  The title change is 
  84.       quite noticeable and *really* ugly.  I found the changing title more 
  85.       offensive than the annoying default title, and since I'm the author, 
  86.       my personal taste settles the matter ;)
  87.       
  88.       
  89. KNOWN CODE GENERATION PROBLEMS:
  90.  
  91.     - None.
  92.       
  93.  
  94.  
  95.  
  96. *************************************************************
  97. *************************************************************
  98.  
  99.    OLD BUGS THAT HAVE HOPEFULLY BEEN FIXED IN VERSION 1.2
  100.  
  101. *************************************************************
  102. *************************************************************
  103.  
  104.  
  105. Code Generation Problems (Hopefully fixed)
  106. *********************************************
  107.  
  108. There were two code generation problems that I knew of in v1.1.  **To the 
  109. best of my knowledge, both of these are fixed in v1.2**  Just in case 
  110. these have not been completely killed, here they are together with their 
  111. work arounds.
  112.  
  113.       (1) Unlabeled COMMON blocks defined in separate C files and 
  114.       declared Extern produces spurious #undef preprocessor statements
  115.  
  116.       This problem occurs when the program contains an unlabeled COMMON 
  117.       block and you have selected the options to define the COMMON block in 
  118.       a separate file and declare the block "Extern" in the original file 
  119.       (the factory default behavior).  In this case the C version of the 
  120.       original FORTRAN file will #define a symbolic constant to refer to 
  121.       the COMMON block (which is translated as a struct).  The error is 
  122.       that f2c will include an #undef statement after the end of the first 
  123.       subroutine in the file -- even if subsequent subroutines refer to that 
  124.       symbol.  This produces a preprocessor error when you try to compile 
  125.       the C file (e.g., "Symbol '_BLNK__1' is undefined").
  126.       
  127.       There are two work-arounds for this bug:  
  128.       
  129.         (a) Do not select the options that define COMMON blocks in separate 
  130.         files and define them Extern.  Unfortunately, this will not always 
  131.         work:  multiple definition errors will occur in the C code when the 
  132.         same COMMON block is used in separate files of FORTRAN code.
  133.         
  134.         (b) Go through the C code and delete the spurious #undef lines.  
  135.         This is usually easy to do and is the recommended solution.  The 
  136.         disadvantage is that this is hard to script if you use a scripting 
  137.         tool of any kind to drive the builds of your FORTRAN code.
  138.  
  139.  
  140.       (2) Make COMMON block members look like local variables produces 
  141.       spurious #undef preprocessor statements.
  142.         
  143.       This problem occurs if you select the option to make COMMON block 
  144.       members look like local variables.  In the this case the C version 
  145.       of the original FORTRAN file will #define a simple symbolic constant 
  146.       to  refer to the elements of the COMMON block (which is translated 
  147.       as a structure).  The error is that some or all of these #defines 
  148.       will be #undef after the end of the first subroutine in the file -- 
  149.       even if subsequent subroutines refer to these symbols.  This 
  150.       produces a preprocessor error when you try to compile the C file.
  151.  
  152.       There are two work-arounds for this bug:  
  153.       
  154.         (a) Do not select the options that mkae COMMON block variables 
  155.         look like local variables.
  156.         
  157.         (b) Go through the C code and delete the spurious #undef lines.  
  158.        
  159.        
  160. ***  AGAIN, I BELIEVE THAT BOTH OF THESE BUGS HAVE BEEN FIXED IN V1.2  ***
  161.  
  162.  
  163.  
  164. The Memory Leak Problem is SOLVED!!!
  165. *********************************************
  166.  
  167. Yes, this problem is fixed in version 1.2.  And that's probably all you 
  168. want to know.  But in case you are a long-time user of Mac F2C, or want to 
  169. know why it was hard to fix, or are just generally curious, below is a 
  170. description of the problem and how I solved it.
  171.  
  172. Versions of Mac F2C prior to 1.2 had a serious memory leak.  The leak 
  173. occurred because the original UNIX version of f2c (incorporated in Mac F2C 
  174. as a subroutine) failed to release memory.  It was quite easy to track down 
  175. the "leaked" memory and free it.  The real challenge was that f2c keeps 
  176. pointers -- many dozens of them -- to that memory.  Free the leaked memory 
  177. and f2c is left with lots of dangling pointers.  Somehow I had to 
  178. "re-initialize" lots of variables, some of which were global, some local 
  179. static variables -- and many of these had to be initialized to non-zero 
  180. values.  Finally, I didn't want to modify the f2c source code too much or I 
  181. would have a maintenance nightmare every time AT&T updated their code.
  182.  
  183. The solution implemented in version 1.2 is conceptually simple.  Before 
  184. executing the f2c "subroutine" I identify the block of addresses where 
  185. "all" the global variables are stored and copy the contents into a handle.  
  186. Then when f2c finishes, I copy the contents of that handle back to the 
  187. original address block.  Presto, all the f2c global variables (including 
  188. static locals) are re-initialized to their original, start-up values.
  189.  
  190. The hard part is identifying the appropriate address block and making sure 
  191. that I'm selective enough to include the f2c globals, but not too much else 
  192. (you get some very interesting crashes if you mess with QD globals or CW's 
  193. SIOUX globals).  The bottom line is that it you can do this using the link 
  194. map, and a bit of experimentation.  The solution I've implemented does NOT 
  195. have self modifying code (which offers one "easy" way to implement this 
  196. "automatically").  However, my implementation requires me to build Mac F2C 
  197. twice: the first time with dummy addresses just to generate a link map, and 
  198. the second time with the correct addresses as determined from the link map.  
  199. And of course, I need to make sure the link map has not changed between the 
  200. two compiles -- something very likely to happen if I accidentally change 
  201. any compiler or linker options or I unknowningly introduce a new variable 
  202. into the global name space through a simple typo...
  203.  
  204.  
  205.